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Abstract 

In ubiquitous computing devices, users tend to store some valuable in- 
formation in their device. Even though the device can be borrowed by the 
other user temporarily, it is not safe for any user to borrow or lend the de- 
vice as it may cause private data of the user to be public. To safeguard the 
user data and also to preserve user privacy we propose and model the tech- 
nique of ownership authentication transfer. The user who is willing to sell 
the device has to transfer the ownership of the device under sale. Once the 
device is sold and the ownership has been transferred, the old owner will 
not be able to use that device at any cost. Either of the users will not be able 
to use the device if the process of ownership has not been carried out prop- 
erly. This also takes care of the scenario when the device has been stolen or 
lost, avoiding the impersonation attack. The aim of this paper is to model 
basic process of proposed ownership authentication transfer protocol and 
check its safety properties by representing it using CSP and model check- 
ing approach. For model checking we have used a symbolic model checker 
tool called NuSMV. The safety properties of ownership transfer protocol 
has been modeled in terms of CTL specification and it is observed that the 
system satisfies all the protocol constraint and is safe to be deployed. 



1 Introduction 

A ubiquitous computing (Ubicomp) or pervasive computing environment is 
imagined as a system with numerous invisible computers, sensors and actua- 
tors interacting with the user devices such as PDAs, Laptops, Mobile Phones 
etc. Data about the individuals who are a part of the ubiquitous environment 
is constantly being generated, transmitted, manipulated and stored. The user 
data present in the environment (in device or servers) is very sensitive. Pro- 
tecting private data of every user in the environment is a major concern. Also 
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in the this era of the mobile environment the user owns more than one portable 
devices like the PDAs, Laptops, Mobile Phones etc. with varying computing 
capabilities in order to access the variety of services that are being provided by 
the service providers. At times the user may tend to sell the device he owns. 
Since the device consists of the valuable information of the user and also will 
have the access to the valuable information present at the server, care should 
be taken to delete the information of the previous owner and store the details 
of the new owner in the device as well as the server. 

Paulo Tarn and Jan Newmarch [1J in their work have suggested the concept 
of transferring the ownership of the device. The owner (old owner) of the 
device will send the message to the device itself that it is being bought by the 
other user (new owner). The device will send the message to the new owner 
saying that its ownership is about to change to you (new user), do you accept 
or reject. The new owner sends the response to the device and the object will 
in turn send an acknowledgment on the status of the transfer to the old owner. 
However when the owner of the device is selling the device to the new owner, 
sending the message to the device itself does not seem feasible. Moreover to 
which device of the user, the device under sale is sending the message is not 
known. It is feasible if the new owner of the device has one more device under 
his ownership. But if the user has no other device previously and it is his first 
device then there is no possibility for the device under sale to send the message 
to its new owner asking his consent on the ownership transfer. In ubiquitous 
environment the ownership transfer has to be informed to the central server 
instead of informing to the device under sale. 

Jurgen Bohn [2j has mentioned that the user can borrow or lend the device 
to his friend or the stranger. The data of a particular user can be retrieved from 
the personalization server at any time and from anywhere for a specific time. 
Once the time limit is exceeded, the session will expire and the user needs to 
quit the session or restart it. After using the device, the user can release the 
device and return it back to the owner of the device. But the very basic idea of 
sharing the personal device with a friend or a stranger may cause information 
to be public. This could be due to the other user being malicious (intentionally 
causing harm) by installing some kind of software which can record the data 
of the user or simply careless (unintentionally installing malicious software 
which can access the users data). Due attention should be paid to the fact 
that the device could come with old data, if the transfer is incomplete due 
to technical reasons such as network congestion or lack of connectivity. The 
owner of the device may also turn out to be malicious with respect to the other 
user. The user may install a software that records all the data that has been 
retrieved and sent from that device before encryption and after decryption. 
Later the user may be subjected to the impersonation attack. Moreover when 
the time limit is exceeded, there are chances that the user may have to end the 
session or restart it due to network latencies or unresponsive server when the 
user is trying to retrieve or release the data. 

Yongming Jin et al [3] has described the transfer of RFID from the old owner 
to the new owner. They define a protocol to safeguard the privacy of the re- 
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spective owners by putting the clean stop between the transactions of the old 
and the new owners by means of a secret. The authors have suggested the use 
of RFIDs for the ownership transfer. But there are many security concerns with 
respect to the RFID tags. One of the primary RFID security concern is the illicit 
tracking of RFID tags. The tags can be read by anyone in the world and if the 
person who read the tag is malicious can pose a risk by either impersonating 
the user or trying to manipulate the user data and use it for a wrong purpose. 
RFIDs working at a shorter range are vulnerable to skimming and eavesdrop- 
ping. Even though certain RFID tags use cryptographic features, the cost and 
power requirements are very high when compare to the simpler RFID tags. 
Thus, the cost and power limitation has compelled some manufacturers to 
implement cryptographic tags using substantially weak encryption schemes, 
which are weak to resist the sophisticated attack. Moreover, the power avail- 
able in the handheld devices is limited; these tags cannot be incorporated in 
the devices. 

Abdullah M. Alaraj |4J in his paper suggest that the users have to go to some 
officially designated place for buying or selling the merchandise and to com- 
plete the process of ownership transfer. He also makes an assumption that the 
certain equipments are required for ownership transfer and tries to improve 
the fairness by including the transfer of money through the bank servers. How- 
ever going to an officially designated place that deals with buying or selling of 
merchandise is suitable only to the goods like cars or for real estate. This sce- 
nario will not be suitable when applied to ubiquitous computing devices. The 
process of ownership transfer requires only a Central Key Server(CKS) and a 
device meant for sale. Submitting users bank details to the third party might 
be risky at the time of payment. Even thought if the system provides the best 
servers for transaction and promotes the users to submit their bank details to 
the device in an office meant for buying and selling of the merchandise, the 
device or the system in that office might turn out to be malicious. 

In this paper we have modeled a newly proposed ownership authentication 
transfer protocol 1 5 1 1 6 1 which overcomes the limitations of the existing owner- 
ship transfer protocol. To the best of our knowledge any form of work in the 
field of formalizing ownership authentication transfer in ubiquitous comput- 
ing devices has been minimal. In this paper, we have described basic process of 
ownership authentication transfer and formalized the safety properties using 
CSP approach. The safety properties of the proposed protocol is verified using 
a symbolic model checking approach. We have used a tool called New Sym- 
bolic Model Verifier (NuSMV) [7]. It searches the entire possible state space 
and checks for the correctness of the various specifications. 

The remaining paper is organized as follows. Section [2] explains the op- 
eration of the proposed ownership authentication transfer protocol. Section 3 
discusses modeling of the proposed protocol using CSP approach. Section 4 
and [5] briefly discusses the concept of model checking and model checker tool 
used. Section[6]explains the modeling about of the safety properties in NuSMV. 
Section [7] discusses about the model checking results obtained for the safety 
properties for the proposed protocol. Finally, a conclusion has been drawn in 
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section |8] 



2 Device Ownership Authentication Transfer Pro- 
tocol 

In this paper we propose a secure and fair protocol for ownership transfer of 
the ubiquitous computing devices. The user who is buying an old device from 
the other user has to undergo this process in order to successfully acquire the 
ownership of the device and start using it in the ubiquitous environment. 

Assumption: The value or the price of the device has been agreed upon 
between the users before transferring the ownership of the device. 

Requisite: The users should be in physical proximity and the whole process 
has to be carried out in the device which is under sale. 



Table 1: Notations Used 



Symbol 


Meaning 


Symbol 


Meaning 


E P C KS 


Encryption Using Public key of 
CKS 


CKS 


Central Key Server 


N A 


nonce generated by A 


N B 


Nonce generated by B 


ID A 


User ID or User Name of the user 
A 


ID B 


User ID or User Name of 
the user B 


PcKS 


Public key of the CKS 


Ack 


Acknowledgment 


PW A 


Password of the User A 


Temp ID 


Temporary ID or Pseudo 
ID 


OTC 


Ownership Transfer Confirma- 
tion 


OTR 


Ownership Transfer Re- 
quest 



The previously existing user should introduce the new owner of the device 
to the CKS, in other words user A must transfer the ownership authentication 
credentials to the new user B. Once the new owner is introduced, the CKS will 
delete the credentials of the previous owner and save the credentials of the new 
owner for the same device. Once the ownership rights has been transfered to 
the new user, the old user at any cost will not be able to use the device. If in case 
the whole process of ownership transfer as mentioned below is not completed, 
neither of the users will be able to use the device. This also takes care of the 
scenario that if a device is stolen, the thief cannot use the device. The proposed 
ownership transfer protocol for a given ubiquitous device is explained below. 

1. U A ^CKS : E PcKS (ID A \\PW A \\N A \\OTR) 

The user A (Old User) sends the message to the CKS. The message con- 
sists of the user A ID, password of the user A, nonce of the user A and 
Ownership Transfer Request (OTR). This message is encrypted using the 
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User A User B Centra I Key Server 



Ep CKS <ID A | | PW„ | | Na 1 1 OTR ) 




Ticket 




Ticket 


Ep cks (ID | 1 N. 1 1 Ticket ) 


E Na (OTC ) 


E N „ (OTC ) 




Epcks < OTC ) 




E Nb (TempID ) 





Figure 1: Diagram Showing Device Ownership Transfer Process 

public key of the CKS. OTR consists of the ID of the user selling the de- 
vice, ID and nonce of the user buying the device. OTR is also encrypted 
using the public key of the CKS, where OTR = Ep CKS (ID A \\ID B \\N B ). In 
this step the user A will introduce user B to the CKS. 

2. CKS ->■ U A : Ticket 

In response to the user A's request for ownership transfer, the CKS sends 
a ticket to the user A. The Ticket consists of the acknowledgment for own- 
ership transfer to the user B. The ticket is encrypted using the public key 
of the CKS. 

3. U B ->CKS : E PcKS (ID B \\Ticket\\N B ) 

The user A will now hand over the device to the user B. Now the user B 
sends his credentials to the CKS. The user needs to send user ID, nonce 
and the ticket got by the user A. The ticket will be in the device itself. 

4. CKS -> U B : £ Na (OTC) 

Once the CKS receives the credentials of User B, the CKS sends the Own- 
ership Transfer Confirmation(OTC) to the user B by encrypting it using 
nonce of the user A. This message consists of the information about the 
money to be transferred and the account details of the destination ac- 
count. 

5. U A -> CKS : E PcKS (OTC) 

The user B will hand over the device to the user A and the user A will 
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decrypt the message, read the acknowledgment and then he sends the 
acknowledgment back to the CKS by encrypting it using the public key 
of CKS. By sending the acknowledgment back to the CKS, he confirms 
the ownership transfer of the device. Signing a particular message twice 
is required to strike the fairness in the deal. There may be some chances 
where either of the users may turn to be malicious. This is done in order 
to obtain a confirmation from the user who is selling the device. 

6. CKS ->■ U B : E NB (TempID) 

On receiving the message, CKS completes the ownership transfer of the 
device by sending the temp ID to the user B. The temp ID is encrypted 
using the nonce of the user B. 

The above explained process of device ownership transfer is summarized 
in the Fig. [T] 

3 Modeling Device Ownership Authentication Trans- 
fer Protocol using CSP Approach 

Communicating Sequential Processes (CSP) |8||9| is a notation for describing 
systems of parallel agents that communicate by passing messages between 
them. Security protocols work through the interaction of a number of pro- 
cesses in parallel that send each other messages. The typical security protocol 
involves several agents (often two: an initiator and a responder) and perhaps 
a server that performs some service such as key generation, translation or cer- 
tification. 

The Yahalom Protocol 1 10 1 representation of Ownership Authentication Trans- 
fer Protocol is as follows. 

Ml A -> CKS : {ID a ■ PW A ■ N A ■ OTR} PcKS 

M2 CKS -> A : Ticket 

M3 B -> CKS : {ID B ■ ticket ■ N b }p cks 

M4 CKS B : {OTC} Na 

M5 A -> CKS : {OTC} PcKS 

M6 CKS -> B : {TempID} N]} 

The basic process of Ownership Authentication Transfer Protocol involves 
two agents: old owner and new owner of the device. The CSP description of 
protocol is given by equation Q. 

The key Pqks is the key of CKS that shares with Old Owner and New 
Owner of the device. The message is encrypted using public key of CKS. 
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01dOwner(A, N A ) 
= env? B 
: NewOwner 
-> send ■ A ■ CKS 

□ 

N A 6 Nonce 
B 6 NewOwner 
m 6 message 



{ID A ■ PW A ■ N A ■ OTR} Pc 



m 



receive ■ CKS ■ A ■ Ticket — > 
send ■ A ■ CKS ■ m ■ {OTC} PcKS 
Session(A, B, P CK s, N A , N B ) 



(1) 



NewOwner (B,Nb) 
□ 

N A e Nonce 
A £ OldOwner 



( send ■ B ■ CKS ■ {ID B ■ Ticket ■ N B }p CKS ->■ \ 
receive ■ CXS ■ B ■ {OTC} N/1 
receive ■ CKS ■ B ■ {TempID}^ B — > 
Session(B, A, P CKSr N A , N B ) 



(2) 



The env? B NewOwner is a representation how the processes local environ- 
ment might tell it to open a session with agent B, this is formally expressed by 
equation |2}. 

Then Yahalom protocol is described as combination of users and servers. 
The Yahalom Process is expressed as: 

Yahalom = OldOwner\NewOwner\CentralKey Server. 

When Intruder is present in the environment, the process is expressed as: 
System = Yahalom] Intruder 



3.1 Safety Properties 

When Intruder is present in the environment, safety properties will be defined 
by introducing additional information into protocol descriptions to enable a 
description of what is expected of the system at particular points during a run 
of the protocol. The user who is buying an old device from the other user has 
to take care of safety properties in order to successfully acquire the ownership 
of the device and start using it in the ubiquitous environment. 

3.1.1 Secrecy 

The old owner sends his credentials and OTR to the CKS. This message is kept 
secret until ownership of the device is transferred to the authenticated new 



7 



owner. The message Claim_Secret will be inserted at the end of the description 
of the protocol run by old owner. Intruder cannot obtain any details during a 
run of the protocol whenever its secrecy is claimed. 

An event Claim_Secret ■ OldOwner ■ NewOwner- message is used. This says 
that the message is kept secret during the run of the protocol. 

The CSP description of secrecy property is given by equation |3| and |4}. 



OldOwner(A, N A ) 
= env? B 
: NewOwner 
->■ send ■ A ■ CKS ■ {ID A 



PW A ■ N A ■ OTR} Pc 



■ m 



□ 

N A e Nonce 
B 6 NewOwner 
m 6 message 



( receive ■ CKS ■ A ■ Ticket 

send ■ A ■ CKS ■ m ■ {OTC}p CKS -> 
signal ■ Claim ^Secret ■ A ■ B ■ Ng — >■ 
Session(A, B, P C ks, N a , N b ) 



(3) 



NewOwner (B,Nb) 
□ 

N A G Nonce 
A G OldOwner 



/ send ■ B ■ CKS ■ {ID B ■ Ticket ■ N B }p CKS 
receive ■ CKS ■ B ■ {OTC} Na -> 
receive ■ CKS ■ B ■ {TempID}^ B — > 
\ Session{B,A,P CKSr N A ,N B ) 



(4) 



3.1.2 Authentication 

The old owner who is selling the device, initiates ownership transfer process 
of the device. In order to formalize authentication properties, two events are 
introduced during run of the protocol. 

• Commit ■ NewOwner ■ OldOwner 

This says that NewOwner has completed a protocol run apparently with 
Old Owner. 



Running ■ OldOwner ■ NewOwner 

This says that OldOwner is following a protocol run apparently with 
NewOwner. 



The CSP description for authentication property of device ownership trans- 
fer is given by equation |5) and 
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OldOwner(A, N A ) 
= env? B 
: NewOwner 

send ■ A ■ CKS ■ {ID A 

-> 

□ 

N A G Nonce 
B G NewOwner 
m G message 



PW A ■ N A ■ OTR} Pc 



m 



I receive ■ CKS ■ A ■ Ticket — > \ 

signal ■ Running JDldOwner ■ A ■ B ■ N A ■ N B — > 
send ■ A ■ CKS ■ m ■ {OTC}p CK$ 

Session(A,B,P CKS ,N A ,N B ) J 



(5) 



NewOwner(B, Ng) 
□ 

N A G Nonce 
A G OldOwner 



send ■ B ■ CKS ■ {ID B ■ Ticket ■ N B }p CKS -)■ 
receive ■ CJCS ■ B ■ {OTC} Na 
receive ■ CKS ■ B ■ {TempID} NB — > 
signal ■ Commit -NewOwner ■ A ■ B ■ N A ■ Nb 
Session(B, A, P CKSr N A , N B ) 



(6) 



4 Model Checking 

As systems to be designed become more and more complicated, it is not suffi- 
cient at all to check the correctness of designs only by simulation. Subtle design 
errors can easily survive even under intensive and massive simulation. Also, 
detecting design errors in the late design stages is extremely costly and must 
be avoided as much as possible. 

Formal verification is to mathematically prove that the behavior allowed by 
given specification (properties) contains the behavior performed by designs. It 
is essentially an exhaustive check on every possible behavior of designs that is 
related to the given specification. 

Model checking is an automatic method to prove such correctness and is 
now becoming to be widely used in real design environments. Model checking 
is basically an exhaustive search in all possible states in the designs by checking 
whether the given specification is satisfied in all of them. That is mostly an 
implicit exhaustive search on state space of designs in the sense that state space 
of designs are represented symbolically instead of individually. This is why 
state-of-the-art model checking programs can verify designs having up to 10 100 
or more states [11 j. 

Specification for model checking is a set of properties that the designs must 
satisfy. Property can be described either in temporal logic or automaton. Tem- 
poral logic is an extension to traditional logic with temporal operators by which 
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we can describe relationships among variables in different time frames. 



5 NuSMV 

NuSMV is a symbolic model verifier tool for the formal verification of finite 
state systems. NuSMV allows us to check finite state systems against specifica- 
tions in the linear temporal logic and Computational Tree Logic (CTL) [12 1. The 
input language of NuSMV is designed to allow the description of finite state 
systems that range from completely synchronous to completely asynchronous 
JT). It provides a modular hierarchical description and reusable component. 
NuSMV is mostly used for describing the transitions of a finite Kripke Struc- 
ture G3. 

NuSMV works only with finite data types such as boolean, scalar and fixed 
array. The main features of NuSMV are its functionalities, architecture and 
quality of implementation. NuSMV allows analysis of specification expressed 
in CTL and Linear Temporal Logic (LTL) using Binary Decision Diagram (BDD) 
and SAT-based checking lH2l . 

We have used NuSMV for modeling basic process of ownership authentication 
transfer protocol and verification of its safety properties. 



6 Modeling Safety Properties in NuSMV 

As per section |3j the secrecy and authentication properties can be viewed as 
model is shown in Figj2]and Fig|3]respectivery. 




Figure 2: Model Showing a Secrecy Claim. 
The various CTL specification for the safety properties can be written as: 
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Protocol I I 

Run 



Figure 3: Model Showing an Authentication Claim. 

• AG(01dOwner(claim_secret)) — > AG(NewOwner(message)) 

This says that the UserA (OldOwner) initiates the ownership transfer 
process with UserB (NewOwner). The UserA claims for the secrecy of 
the message. The message is kept secret during run of the protocol. In- 
truder cannot access any kind of details of the session. 

• AG(01dOwner(Running)) — > AG(NewOwner(Commit)) 

This says that the during the run of the protocol UserA is committed to 
UserB. UserB is following protocol run with UserA. Any kind of infor- 
mation is not revealed to the intruder present in the environment. 



7 Model Checking Results and Discussion 



Table 2: Specifications of the Protocol 



Sl.No. 


Case 


Specification 


1 


UserA[l]=l & UserA_claim_secret[l][2]=l 


True 


2 


UserA[l]=l & UserA_commit[l][2]=l 


True 


3 


UserB[2]=l & UserB_running[2][l]=l 


True 


4 


UserC[2]=l &UserC[2][l]=0 


False 


5 


UserC[l]=l &UserC[l][l]=0 


False 



Table|2]shows the various constraints imposed on the system and results of 
the corresponding specifications. 



11 



1. The first specification in the table depicts that User A (Old Owner) ini- 
tiates the ownership transfer process with UserB (New Owner), sends 
message to the CKS. The message consists of the UserA ID, Password, 
Nonce and OTR. The UserA claims for the secrecy of the message so 
that intruder present in the environment cannot access the details of the 
session. The secrecy property is verified through this specification. The 
specification simulation is shown in Figj4] 



c Select Command Prompt - 



III > go 
MShTI > checkjtlspec 

- specification AG (((((userd.sendJIM S userfl .send_PassuordA> ii userA.sendJo 
icell) It userfl . Authent icate> It KuserA.status = other)) ■) tX userA.conf irn_0wner 
hipfransferRepestll) is true J 

lusnu > 



Figure 4: First Specification Verification Result Showing Result as True. 



The second specification in the table shows the specification as true be- 
cause the UserA(old user) introduce UserB(new user) to the CKS. UserB 
sends ID, Nonce and Ticket to the CKS. The UserA is committed with 
UserB. The specification simulation is shown in Figj5] 

The third specification in the table shows the specification as true because 
the UserA(old user) introduce UserB(new user) to the CKS. UserB sends 
ID, Nonce and Ticket to the CKS. The UserB is running with UserA. The 
specification simulation is shown in Figj5] 



OWS\system32\cmd.exe - NuSMV 



I > go 

Ml > checkjtlspec 

specification AG ( « < <userB . sendjl I DB & userB.sendJonceB) $ userB.sendJicke 
t) 8 userB.Authenticate) t ! (user! .status = other)) -> fill userB.OwnersliipIransfe 
^Confirmation) is true 

II > 



Figure 5: Second Specification Verification Result Showing Result as True. 



4. The fourth specification says that UserC (Intruder) sends credentials of 
UserB to the CKS, trying to access the device. This is not possible. The 
specification returns false and counter example will be generated. The 
specification simulation is shown in Figj6] 

5. The fifth specification says that UserC (Intruder) sends UserA credentials 
to the CKS, trying to initiate the ownership transfer process of the device. 
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NuSMV int auth.! 



e> & 



> check_ctlspec 
icification AG <(<<userC. 
! (userC. status = other)} 



end_UIDB & userC.send_NonceB> & uaerC.Authentii 
> AG userC.QwnershipTransferConFirmation) is 1 



— as demonstrated hy the following execution ; 
race Description: CTL Counterexample 
race Type : Counterexample 
> State: i.I <- 

userA. UID - 1 

userA. Password = 1 

userA. Nonce = i 

userA. OunershipTransferRetiueEt = 1 
userfl.Ticliet = 
userA. sendJJIDA = 
userA. send_PasswordA ~ 
userA. send_NonceA = B 

userA. send_OwnershipTransferRec[uestfl = 
userA. send_Ticket = 
user A. Authenticate - 
userA. confirnJJIDA = 
userA.conf irm_PasswordA = 
userA.conf irm_NonceA = 

userA.conf irm_OwnershipTransferReQ;uestfl = 

userA.conf irnJTicket = 

userA.sendJJIDB - 

userA. send_NonceB = 

userA.conf irm_UIDE = 

userA.conf irm_NonceB = 

userA. sendJJIDC = 

userA. send_NonceC = 

userA.conf irnJJIDC = 

userA. confirnJIonceC = 

userA .OunershipTransFerConF irnation = 

userA. status = other 

userB.UID = 1 

use rB. Pas sword = 

userB. Nonce = 1 

use rB. Oun e rsh ipT ran sfer Re quest = 
userB. Ticket = i 
userB.send_UIDA - 
userB.send_PasswordA = 
userB.send_NonceA = 

userB.send_OwnershipTransf erRequestfl - 

userB. sendJTicket = 

userB. Authenticate = 

userB. conf irmJJIDA = 

userB. conf irri_PasswordA = 

userB. conf irn JlonceA = 

userB. conf irn J)wnershipTransf erReuuestfi = 

userB. conf irn_Ticfcet = 

userB. sendJJIDB = 

userB. send_NonceB = B 

userB. conf irri_UIDB = 

userB. conf irin_NonceB = 

userB. sendJJIDC = 

userB. send_NonceC = 

userB. conf irnJJIDC = 

userB. conf irri_NonceC = 

userB. OunershipIransFerConf irnation = 

userB. status = other 



Figure 6: Fourth Specification Verification Returns False and Gives a Coun- 
terexample. 
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The specification returns false and counter example will be generated. 
The specification simulation is shown in FigJT] 



JuSnU > check_ctlspec 

- specification AG (<<(<userC.send_UIDA & us. 
ceA) & userC.Authenticate> & TtuserC. status 
hipTransFerBequestA> is false 
— as demonstrated by the following execution sequence 
race Description: CTL Counterexample 
pace Type : Count erexanple 
> State: 1.1 <- 

userA.UID = 1 

userA. Password = 1 

userA. Nonce = 1 

userA. OwnershipTransFerRequest = 1 
userA. Ticket = 
userA. send_UIDA = 
userA. send_PasswordA = 
userA .send_NonceA - B 

userA. send_OwnershipTransferIlequestfl - 

userA .send_Iicket = B 

userA. Authenticate = 

userA. confirm_UIDA = B 

userA. conf irm_PasswordA = 

userA .conf irm_NonceA = B 

userA. conf irm_OwnershipIransferRequestA = 

userA .conf irm_T icket = 

userA. send_UIDB = 

userA. send_NonceD = 

userA. confirmJJIDB = 

userA. conf irm_NonceB = 

userA. send_UIDC = 

userA. send_NonceC = 

userA. confirmJJIDC = 

userA. conf irm_NonceC = 

userA .OwnershipTransFerConFirnation - B 

userA. status - other 

userB. UID = 1 

userB. Password = 

userB. Nonce = 1 

userB.OwnershipTransFerRequest = 
userB. Ticket = 1 
userB. send_UIDA = 
userB. send_PasswordA = 
userB.send_NonceA = 

userB .send_OwnershipTransf e rile quest A = 

userB. send_Iicket = 

userB. Authenticate = 

userB. conf irm_UIDA = 

userB. conf irm_PasswordA = 

userB. conf im_NonceA = B 

userB. conf irm_OwnershipTransf erRequestA = 

userB. conf im_Ticket = B 

userB. send_UIDB = 

userB. send_NonceB = B 

userB. conf irm_UIDB = 

userB. conf irm_NonceB = B 

userB. send_UIDC = 

userB. send_NonceC = 

userB. conf irm_UIDC = 

userB. conf irm_NonceC = 

userB. OwnershipTransferConFirnation = 

userB. status = other 

userC.UID = 1 

userC. Password = 



Figure 7: Fifth Specification Verification Returns False and Gives a Counterex- 
ample. 



8 Conclusion 

In this paper, we have proposed a new ownership authentication transfer pro- 
tocol for ubiquitous computing devices. The basic process of ownership au- 
thentication transfer and safety properties is described using CSP approach. 
We have used symbolic model checking approach to model the safety prop- 
erties of the proposed protocol. The tool NuSMV helps us to verify the con- 
straints imposed on the system by exploring the entire state space of the sys- 
tem. It provides a counter example along with the trace path to point to the 
location of error, if the system does not meet any of the constraints. The safety 
properties of a protocol is modeled efficiently using NuSMV. It is observed that 
all the constraints are met by the system developed and the proposed protocol 
is safe to be used in Ubiquitous environment. 
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